home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1105 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  6.5 KB
  1. From: Mark.Baker@mettav.exnet.com (Mark Baker)
  2. Date: 27 Jul 94  19:52:22
  3. Message-Id: <UUCP.775429226@mettav>
  4. Subject: Re: GEM-List 
  5. To: gem-list@world.std.com (gem-list@world.std.com)
  6. Precedence: bulk
  7.  
  8. Warwick:
  9.  > Now he's arguing with the author of the library about its size, when
  10.  > the archive is sitting there for all to see, at atari.archive.  The
  11.  > archive is dated 23/11/93, and contains files with the sizes I quoted
  12.  > above.  As for `they bombed more often than not', I can say that the
  13.  > example.prg of GEM++ 1.99 only runs on 68030 machines, due to GCC 2.5.7
  14.  > being used to compile it.
  15.  
  16. It crashes on my Falcon as well, as I've already emailed you about. The
  17. editable fields in Nethack crash as well. Could this be a conflict with LTMF?
  18.  
  19.  > This is a different issue.  Graphics cards can perform screen-to-screen
  20.  > blit operations much faster because they use on-chip acceleration.
  21.  > Blitting mainmemory-to-mainmemory is usually pretty fast too.  But blitting
  22.  > between the RAM on a graphics card and mainmemory is the bottleneck I was
  23.  > talking about.
  24.  >
  25.  > I know it might be hard to resist thinking of one's own machine as the
  26.  > target for one's software and optimizing for that, but this really must
  27.  > be avoided, especially by anyone want to follow a standard.
  28.  
  29. But surely optimising for STs, TTs and Falcons, with or without Overscan,
  30. Blowup etc, is better than optimising for graphics cards which a tiny minority
  31. have.
  32.  
  33.  > This opens up a large relm of possibilities if this can become a common
  34.  > feature of GEM applications:
  35.  >
  36.  >  1. Point-to-type
  37.  >  2. Exit highlighting
  38.  >  3. Pointer-form change
  39.  >  4. Balloon help (ala Mac)
  40.  >
  41.  > Now, at first glance, many of us would say "NO!" to at least 3 of
  42.  > those, but our main reason would be "It's not GEM".  Yet, it *is* GEM.
  43.  > I'm using GEM to do it, and do it efficiently.  Most applications don't
  44.  > make any use of the event rectangles... because they didn't implement
  45.  > any of these `hot' features.  (I take the term hot from Tim Oren).
  46.  
  47. Pointer form change I would definitely support and it _has_ been around since
  48. day one. But not the others. Point-to-type is confusing IMO, and would be even
  49. were it not totally different to GEM conventions. As for exit highlighting I
  50. can't see any point in it, although it is harmless. It doesn't look very nice
  51. with 3d buttons though. Balloon help... why not, it's a pity there isn't an
  52. efficient way to track menus (it can be done using timer events)
  53.  
  54. Tim:
  55.  > Here's an idea for operating back-ground windows...  put an event
  56.  > rectangle around your window and watch for the mouse to move outside of
  57.  > your window.  When it does, monitor all mouse activity
  58.  > [wind_update(BEG_MCTRL)], and when you get a click, process it.  If it's
  59.  > an action on one of YOUR windows, then select buttons, whatever; top if
  60.  > necessary.  If it's someone else's window, send a message to the
  61.  > application, telling it to top the window.
  62.  
  63. What if you get a click on another window but outside the client area? GEM
  64. doesn't guarantee the positions of the gadgets, so what would you do?
  65.  
  66.  > 1.  When you find another app's window and find out its handle, how do
  67.  > you get the application ID of that app so you can send it a message?
  68.  
  69. Only possible with aes >= 4 AIUI. You use wind_get().
  70.  
  71.  > 2.  How do you detect the presence of MultiTOS?
  72.  > 3.  How do you detect the presence of Geneva?
  73.  
  74. Depending on what exactly you want it for, test the aes version in
  75. _AESglobal[0], or the number of concurrent applications in _AESglobal[1] (names
  76. for lattice, the array has a slightly different name under other compilers)
  77.  
  78. To distinguish between Geneva and MultiTOS
  79.  
  80.  > 5.  My compiler (Lattice C 5.6) has full support for MultiTOS... what do
  81.  > I do about Geneva?
  82.  
  83. Geneva supports most of the new aes features of multitos, although you should
  84. check appl_getinfo(). It doesn't support any of the MiNT extensions. As for
  85. Geneva-specific functions I'm not sure how to get these or even if there are
  86. any. They should be in the manual for Geneva.
  87.  
  88.  > Oh, and objc_edit code would be nice too.  :)  Although, I don't believe
  89.  > in sending keypresses to anything other than the top window, so
  90.  > replacement objc_edit wouldn't be very useful.  <shrug>
  91.  
  92. Except when you receive a click on a text field in an untopped window, when you
  93. do objc_edit(ED_INIT...) the cursor is not drawn clipped.
  94.  
  95. ???:
  96.  > Since it removed the desktop form, why do the icons still show up?
  97.  
  98. If the background of the desktop installed is transparent, or too small, the
  99. icons of other applications show through. But they don't work.
  100.  
  101.  > Sure, some things would be nice as configurable, but we know more about
  102.  > userinterfaces than the average user (for the most part), and we can
  103. :)
  104.  
  105.  > figure out what works well as compared to what is absolutely moronic.
  106.  
  107. Yes, I don't think we should require user configuration apart from for keyboard
  108. shortcuts. If anyone wants to deviate from the standard by, for example, using
  109. their own fileselector, click to type in background windows or any other thing,
  110. by all means have it as a user option (and certainly don't force it on the
  111. user). But don't say we all have to have it as an option, it's just your
  112. non-standard program.
  113.  
  114. Michel:
  115. [Atari compendium]
  116.  > These are textual errors, but it makes me question what -other- errors
  117.  > there might be.  Is the code listed reliable?  Are the suggested
  118.  
  119. The bindings are very unreliable. For a high level programmer it's mostly
  120. pretty good although there are a few mistakes.
  121.  
  122.  > because the upgrade price is actually the same price (or more expensive)
  123.  > then the price they could purchase it for.  The feeling seems to be that
  124.  > the upgrade should have been offered as a text file or addendum-booklet
  125.  > to registered owners.
  126.  
  127. There is an addendum with the error fixes in, but not the new material.
  128.  
  129. Simon:
  130.  >> The file should go on the root directory of the boot drive. All this has
  131.  >> been discussed but not finalised yet.
  132.  >
  133.  > I'd like to see something similar to the system folder on the Mac. Yes we
  134.  > can make it fall back to the root directory for those who don't know or
  135.  > care about neatness, but to be frank I'm growing weary of a cluttered C:\
  136.  > directory.
  137.  
  138. Personally I use the whole of my drive C: as a system folder with everything
  139. else on D: (which is minixfs). You don't really want it to be exactly like the
  140. mac's system folder, which AIUI is not really a folder at all but actually a
  141. way to look inside the system image file.
  142.  
  143. But I agree with your proposal, it would make sense to do this. How about
  144. putting everything in the multitos folder though?
  145.  
  146.  
  147.  
  148.